home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Almathera Ten Pack 2: CDPD 1
/
Almathera Ten on Ten - Disc 2: CDPD 1.iso
/
pd
/
276-300
/
279
/
mrbackup
/
changes
< prev
next >
Wrap
Text File
|
1995-03-14
|
5KB
|
97 lines
Changes
=======
This file lists changes, in reverse chronological order, as they have
appeared in official releases of MRBackup. I have attempted to be
thorough, but may have missed a few key items.
Version 3.3e, October 1989
There was a NASTY! bug in version 3.3d that prevented MRBackup from
copying files larger than 32k. It's fixed. The cause of the bug was due
to an attempt to improve MRBackup's use of "buffer" memory. I had the flu
at the time and apparently passed it on to MRBackup :-). The improvement
has been achieved (correctly) in this release. A new asynchronous file
copy routine employs smarter use of buffers and cuts down dramatically on
inter-buffer data movement. This should manifest itself as a minor
improvement in copying (not compressing) speed.
There was a problem with the setting of archive bits which manifested
itself with filenames containing certain punctuation characters, such as
"#", "(", "'", etc. If those characters were present in the volume name,
you'd get error 218 (volume not mounted). If they showed up in the
filename, you'd get error 205 (object not found). It's fixed.
In version 3.3d, I attempted to keep the Status gadget "fresh" by resetting
it to "Idle." at the top of the event loop. Unfortunately, this would
cause some important status messages to be erased. This behavior has been
changed such that the field is erased just prior to processing certain
events (gadget, menu, etc.). If the processing of these events should
cause a status update, the information is not lost.
A lockup condition could be encountered when using the pathname request
gadget for the log file. This has been fixed. In fact, I've improved the
behavior of all of the pathname requesters. You should no longer see the
message "Directory Error" flash in the requester, unless, of course, you
type an erroneous directory name directly into the requester (or click on
an unmounted drive specification).
If you attempted to specify an unmounted floppy drive for the "Home Path",
you'd get the error message "Home path must specify a device or directory".
This message was not specific enough and could be confusing. It has been
changed to "Home path must specify a mounted device or directory". It's OK
to specify df0:, etc., as your Home Path. Just be sure that the diskette
you're going to use is inserted in the drive before doing so.
The size of MRBackup's custom screen and windows should now adapt to your
system defaults. This should be helpful on European systems, especially.
I would appreciate feedback on the results of this change, since I can only
test it on my A1000 NTSC system.
In Utilities, if you performed any operation which modified the target (To)
and then clicked on the To switch, the display was not updated to reflect
the change. This has been corrected. Thanks, Tom.
Version 3.3d, September, 1989
This release came about largely as a result of conversations I had with Tom
Zartler of West Chester, Pa. Tom reported a couple of bugs and offered
some suggestions that will show up in version 4.0 (which is well on its
way!).
The Rename function in the Utilities window was brain-dead. It's been
fixed.
If you copied a file using the utilities and the From/To selections were on
the same disk, the result (for large files, anyway) was a slow, tedious
grind. This was due to the use of asynchronous I/O in a situation where it
obviously was counterproductive. MRBackup now chooses between
synchronous/asynchronous I/O. Asynchronous I/O is used when the From and
To devices are different.
Tom suggested that when the Set Archive Bits option was enabled, the backup
copy of the file should have its archive bit set, as well as the original
file. I think someone else recommended this also, but I was too dense at
the time to realize what was being said. What's implied here is the fact
that since the file exists on a backup disk, it IS archived. If you should
restore from that disk, the archive status is still valid. Agreed!
If you left Utilities with either of the "scan switches" enabled, upon
return you would find that they didn't function properly. MRBackup now
resets the switches prior to first use.
I may catch some flak for the most obvious change. You'll notice that all
of the gadget borders are gone. I dunno- sometime a week or two ago, I
decided that all those boxes on the screen were U-G-L-Y! I hope you agree.
MRBackup is more efficient in its use of buffer memory for
copying/compressing files.
Some of you complained that the abrupt color change after MRBackup loaded
its parameter file was unsettling. I had some fun with this one and
implemented a more gradual color shift that has a nice effect. It's more
pronounced, the more your colors differ from MRBackup's defaults.